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ABSTRACT 



A technique, specifically apparatus and accompanying 
methods, for use in a client-server environment for booting 
an operating system (O/S), such as a 32-bit personal com- 
puter (PC) O/S, on a client computer through a networked 
connection to a server. Specifically, the server stores an 
image of a client hard disk including the client O/S and 
desired applications. During a boot process, a procedure, 
which is compliant with both an interrupt handler in the 
client and a network driver kernel in the client O/S, is 
installed in the client. Based on client O/S resources then 
available when, during the boot process, the client requests 
a local hard disk access to a particular sector, the procedure 
will re-direct that request, to the network file server, through 
a network driver kernel in the client O/S rather than through 
a client interrupt handler. Each such request is processed, to 
provide physical sector read or write access, through my 
inventive random access trivial file transfer protocol 
(RATFTP) server executing in the network server. 
Advantageously, the source of the sectors remains transpar- 
ent to the client O/S, while it is being booted from a network 
connection, in lieu of a local hard disk drive. Hence, client 
hard disk emulation occurs seamlessly and continuously 
throughout the entire boot process even though, during this 
process, the client processing mode changes from real to 
protected and the client O/S resets and gains control of a 
cHent network adapter. 

39 Claims, 14 Drawing Sheets 
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500 



# Blank lines and Unas beginning with '#* are ignored. 

# Each entry in the file contains a name for the entry and a series of 

# fields, seperated by a colon. Fields are defined by a two character 

# "tag", supported tags are: 
« 

# ha - hardware address 

# ip - host IP address IP addresa CIC^ CA 

# hd - homo directoxy f" I vjl ■ O^* 

# bf - bootfile 

# bs - boot server IP address 

# cs - cookie server IP address ROOTPTAR 

# ds - domain name server IP address D\-/V.J I i I MD 

# gw - gateway IP address pil p 

# hn - return host name i IL.C 

# dn - return host domain name 

# im • impress server IP address 

# Ig - log server IP address 

# Ip " I*PR server IP address 

# sm - subnet mask ) 

# tc - template host (points to similar host entry) J 

# to - time offset (seconds) 

# ts - time servers 
« 

« Fields within entries may appear in any order. Spaces and tabs in lines 
4 are ignored. An entry can span more than one line in the file by ending 

# continuing lines with a backslash. 

#DBfault tes^late used by all hosts, 
defaultation :hn : sm=255 . 255 . 0 . 0 : vro=rf cl048 : to=3600 : 

# a simple host entry 

# John : tc=default :ha=OOC0930067D2 : ip=132 . 147 . 001 . 1 :bf=john. img ; 

# a entry that uses more than one line 

# Pau 1 : tc=do f aul t : \ 
» ha=O0A024823421:\ 

# ip=132.147.180.4:\ 

# bf=paul.img: 

#Frod: tc=def ault :ha«0000F4B048CA: ip=132 . 147 . 180 . 7 :bf =win95 . img: f^QH 
iSteve: tc=def ault:ha=00001B4 9D9D7 : ip=132 .147 . 180 . 10 : bf=win95 . img : O^KJ 
#Conrad:tc=def ault :ha=02 0701 0422A7 : ip=132 .147.180.5: bf=win95 . img : 

LanHD L : tc=def ault :ha=00A024B82705 : ip=132 ,147.001. 5 :bf=lanhd. img : 

LanHD"2 : tc=def ault :ha=00AO24BAF9A5 : ip=132 .147.001.6: \LANHD\ :bf=lanhd. img: V ^^l f) 
LanHD_3:tc=default:ha=00608Cri5EA3:ip=132,147.001.7:\LAKHD\:bf«lanhd.img: | ^ 



#1 : ip=132 . 147 , 170 . 001 ;hd=c : \lanhd\d. 
[OOeOeCFlSEAB] ; 3c5x9 

#1 : ip=132 .147.190. 005 ; hd=e : \lanhd\diskl50 



FIG. 5B 
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[0OA024Baf9a5] ; 3c90x FILE 
#1 : lp«132 .147.001.001 /hd^c : \lanhd\dl8lcl5C ; 

550 

(00A024B82705] ; 3e5x9 ^ 
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TECHNIQUE FOR RELIABLE NETWORK extended past just a single application to encompass all or a 

BOOTING OF AN OPERATING SYSTEM TO set of applications that would be common to most, if not all, 

A CLIENT COMPUTER of the PCs on a network. By doing so, the intent would be 

to eliminate a need to separately administer the software 

BACKGROUND OF THE DISCLOSURE s stored on every single workstation on the network in favor 

1 ij f T I' of doing so just once — on a shared installation image on a 

1. Field of the Invention a* r • ^- * . j 

server. Moreover, as part of these initiatives, automated 

The invention relates to a technique, specifically appara- techniques are being developed to permit such administra- 

tus and accompanying methods, for use in a client-server tion to occur remotely through the network thereby ehmi- 

environment for booting an operating system (O/S) on a nating any need for an individual to physically visit each 

client computer through a networked connection to a server. such PC and personally service its software. 

This technique is particularly, though not exclusively, suited achieve effective centralized administration of network 

for use in booting 32-bit personal computer (PC) operating ^^^^15, ideally a server should store a complete image of the 

systems and can be advantageously used to simplify system software, including the operating system (O/S), utihzed by 

administration and significantly reduce administrative costs ^ client computer. As each client computer is powcred-on by 

m, e.g., large enterpnse environments. ^^^^^ ^^^^ ^^^^^^ ^o^l^ establish a connection with the 

2. Description of the Prior Art server and boot its operating system from the server. In 
Over the past decade, personal computer (PC) usage has particular, an operating system image would be stored on the 

increased substantially to the point where currently PCs server and would be transferred, via the network, to the 

(including workstations) have diffused into many aspects of client onto which that operating system would be set-up and 

a business organization. Coincident with this phenomena, a run. Application software could then be transferred from the 

desire has increasingly arisen among computer users in a server, as needed, to the client and then run on the client, 

common organization to readily share computer files. This Proceeding in this fashion could ehminate the need for any 

desire, particularly when fueled by historically decreasing hard disk storage on each client, thereby facilitating use of 

costs of network equipment, has led to an expanding number 25 low-cost "diskless" computers. Alternatively, application 

of network installations throughout the business community software could remain on the server and be executed there;:, 

to facilitate file sharing and electronic communication not from, 

only among users in a common organization, but also with Unfortunately, serious impediments exist that, in practice, 

users at other organizations and locations. Moreover, as effectively limit the extent to which a client computer can be 

these costs of increasingly sophisticated PCs and network 3Q centrally administered and, specifically, a client O/S booted 

equipment continue to fall, networked computer usage is from a network server. 

penetrating increasingly smaller organizations as the Currently, a common and widely used 32-bit PC operating 

expected benefits to those organizations, such as expanded system, specifically Windows 95 O/S available from 

productivity, outweigh the costs associated therewith. Microsoft Corporation of Redmond, Washington (which 

If current cost and technology trends continue, PC usage 35 also owns the registered trademark "Windows 95"), pro- 
should ideally proliferate throughout businesses to a point of vides rather fimited and problematic server-based set-up 
becoming rather ubiquitous and inter-connected, i.e., at least abilities. Ideally, for server-based set-up of a client PC, the 
ideally and at some time in the future where most people will client O/S should be bootable from either a system floppy 
possess their own PC and where such PCs will become diskette or a ROM, situated within the PC, and then down- 
increasingly inter-networked with each other. 40 load all the other system files from a network file server. The 

However, in reality, a significant impediment to network- ROM would store suitable code that emulates the floppy 

ing has been and continues to be cost — not just the initial disk. 

and replacement cost of hardware, i.e. each computer and At present, in practice, during the course of configuring a 

associated network equipment, and the time and effort particular client computer for server-based setup of the 

required to successfully connect them together, but also the 45 Windows 95 O/S, this O/S would create two directories on 

cost of administering, on a post-installation basis, each and the client computer for subsequent transfer to a server: a 

every networked computer This latter cost, which often machine directory which stores configuration information 

vastly exceeds the cost of the former, includes the cost of for that specific client, and a share directory which contains 

servicing, including updating, the software stored on each shared O/S files. During the boot process, both directories 

and every networked computer. In a typical enterprise envi- 50 are used to control the remainder of the set-up process and 

ronment having thousands or tens of thousands of networked load appropriate O/S files onto the cUent. It was empirically 

client PCs — ^which is very common today, it is very expen- found that, from time to time — though not all the time, while 

sive for a network administrator, or more generally speaking creating the directories on the server, the client computer 

in a large enterprise a member of an information technology would simply halt, i.e. "freeze". In other instances where the 

(IT) department, to physically visit each user and service 55 directories were successfully created, users found that some- 

his(her) client computer as required. Inasmuch as a predomi- times during the network boot process, the client computer 

nant component of total post-installation administrative would also halt — again from time to time, though here too 

costs is for cHent software, software and computer manu- not always. Moreover, apart from these problems, the Win- 

facturers have recently embarked on various product initia- dows 95 operating system, as it currently stands, apparently 

tives aimed at reducing the cost of maintaining installed 60 does not support network booting through a 32-bit local area 

client software. For the most part, these efforts, as they relate network (LAN) adapter. While 16-bit ISA (Industry Stan- 

to software manufacturers, arc expected to involve provid- dard Architecture) network (e.g., LAN) adapters were preva- 

ing a version of their software products that can be installed lent at the time the Windows 95 O/S was introduced, 

and centrally maintained on a network server and then currently 32-bit adapters, particularly PCI (Peripheral Com- 

identically downloaded as a single image, via the network, 65 ponent Interconnect) type adapters predominate a network 

to each and every client PC on which that software is to be adapter market. Lastly, difHculties arose in changing a 

installed. This concept, as currently envisioned, could be server-based installation of a Windows 95 client, thereby 
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frustrating centralized remote administration of the applica- 
tion software to be downloaded to that client. 

Given these difficulties, the art has apparently veered 
away from the concept of providing server-based setup of a 
32-bit PC 0/S in favor of using different approaches for 
centralized client administration. One such approach relies 
on using an inexpensive client PC, i.e., a so-called "thin 
client", to essentially transmit user keystrokes to a server at 
which they are processed and at which applications are run. 
The results wotild then be retturned, via the network to the 
client PC, and displayed to the user through an appropriate 
graphical user interface executing at the client PC. While 
this approach eliminates a need to store and execute appli- 
cation software on a client PC, it does so at the expense of 
shifting application processing to a network server. In a large 
networked environment, the added processing load placed 
on the server could render this approach impractical. While 
the use of inexpensive PCs, such as "thin clients" and 
diskless" PCs certainly have merit to reduce costs and 
centralize administration in large networked enterprise 
environments, such PCs, as presently envisioned, still 
require an operating system, which, for effective centralized 
administration, should be booted from a network. 

Therefore, a need exists in the art for a technique, spe- 
cifically apparatus and accompanying methods, for use in a 
client-server environment for reliably booting an operating 
system, such as a 32-bit 0/S, on a client PC from a network 
server. Moreover, such a technique, should be fully opera- 
tive with aU cunently available LAN adapters, whether, e.g,, 
16- or 32-bit and permit changes to be easily made to any 
server-based installation of client software. Throtigh use of 
such a technique, the processing load on the network server 
(s) can be advantageously reduced by utilizing local client 
RAM memory and CPU resources, rather than server 
resources, for client apphcation and client 0/S processing. 
Consequently, by utilizing these client resources, server 
complexity and cost, such as those occasioned by large 
amounts of RAM and multiple CPUs that might otherwise 
be required, could be sharply reduced. By virtue of meeting 
these needs and being capable of network booting an 0/S, 
such as the Windows 95 0/S, on substantially any client PC, 
including thin-clients and diskless PCs, such a technique 
should find widespread use in implementing effective cen- 
tralized client administration in, e.g., large networked enter- 
prises and in providing significant administrative cost sav- 
ings. 

SUMMARY OF THE INVENTION 

The present invention overcomes the deficiencies in the 
art and satisfies these needs by providing, through a network 
server, seamless and continuous client hard disk emulation, 
at a physical sectorized level, throughout the entire boot 
process even though, during this process, various 0/S files 
are downloaded and 0/S processes are activated which 
collectively change a client processing mode from real to 
protected and which reset and gain control of a network 
adapter in the client. 

In accordance with my inventive teachings, a network 
server stores an image of a client hard disk, including the 
client O/S and desired applications. Rather than directing 
each request that arises during booting of the client 0/S, for 
a specific sector of a stored file to a local hard disk on the 
client, an inventive transport driver, which is downloaded 
and installed on the client as part of the client 0/S, redirects 
that request to the network server to retrieve and download 
that sector, from the client hard disk image, to the client. As 
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a result, the source of the sectors remains transparent to the 
0/S, i.e., the client 0/S is unaware that it is being booted 
remotely from a network server in lieu of a local hard disk 
drive. Each such request is processed through my inventive 
random access trivial file transfer protocol (RATFTP) server 
executing in the network server to provide read/write sec- 
torized access to the client image file. 

Specifically, whenever a user energizes a client computer 
(such as, e.g., a PC), this PC establishes a network connec- '-^ 
tion to the network server and issues a boot request to that / 
server. In response to this request, the network server 
downloads sufBcient files from the stored client 0/S image 
to the client PC to permit the client to boot the 0/S and 
continue loading the required 0/S files from that image. 

During booting, the client PC initially operates in a real \ 
mode and then, based on the client 0/S processes then I ^ 
initiating, transitions to a protected mode. \ 

While the boot process is occurring but prior to the 
availability of any cHenl 0/S-based network support, client 
hard disk emulation occurs through appropriate calls made 
to an interrupt (Interrupt 13 or simply "Int 13") handler. 
Through such calls, appropriate sectors in the client image 
file are initially downloaded, via a real-mode network 
adapter (NIC) driver and the Int 13 Handler to remotely 
install various components of the 0/S into chent PC. The 
actual client hard disk emulation process is provided through 
a real mode procedure that executes as part of Int 13 
Handler. In essence, the real mode procedure determines, 
based on values of status flags, whether the client 0/S is then 
capable of handling a network request for sector access of 
the chent image file. If the client 0/S has not then progressed 
to that point in its boot process, the real mode procedure 
processes that request, in real mode, through the Int 13 
Handler, 

As a client 0/S kernel is installed and initialized during 
the boot process, the kernel installs and activates various 
device drivers, including the inventive LANHDVSD.VXD 
procedure. This procedure is compliant with both the Int 13 
Handler and with the 0/S, specifically, in the case of 
40 Windows 95 0/S, a network driver (NDIS — network driver 
interface specification) kernel therein and the 0/S input/ 
output subsystem (lOS). The inventive procedure, which 
executes as a protected mode driver, contains two asynchro- 
nous procedures. These asynchronous procedures, by setting 
45 and testing appropriate flags used as processing state 
semaphores, collectively control the transition of hard disk 
requests to the networked chent image from the Int 13 
Handler to the client 0/S depending upon, as the client 0/S 
is then booting, the 0/S resources that are then available 
50 During early phases of the boot process, insufficient 0/S 
components have been loaded and activated to provide client 
0/S supported network access. Consequently, client hard 
disk access requests arc handled through the Int 13 Handler. 
Whenever sufficient 0/S resources become available to 
55 permit network access through the client 0/S, the asynchro- 
nous procedures permit these requests to be serviced by the 
NDIS and I OS components of the client 0/S, so as to 
provide 0/S supported network access, rather than by the Int 
13 Handler. Hence, these asynchronous procedures collec- 
60 lively assure, in conjunction with Int 13 Handler, seamless 
and continuous client hard disk emulation during the real^,,^ 
protected transitory state. 

Inasmuch as client hard disk emulation occurs at a 
physical, i.e., sector, level, rather than at a higher level, my 
65 present invention, as one of its features, is independent of 
and properly operates with substantially any particular chent 
file system, whether it is, e.g., FAT, FAT32, HPFS or NTFS. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The teachings of the present invention can be readily 
understood by considering the following detailed descrip- 
tion in conjunction with the accompanying drawings, in 
which: 

FIG. 1 depicts a high-level simplified block diagram of 
client-server environment 5 in which illustratively client 
personal computer (PC) 10 is to be booted through server 50 
in accordance with my inventive teachings; 

FIG. 2A depicts a block diagram of environment 5 
showing, in additional detail, various elements of my present 
invention; 

FIG. 2B depicts an alternate embodiment of client hard 
disk image files as could be stored on hard disk 54 within 
server 50 shown FIG. 2A; 

FIG. 3 depicts a high-level block diagram of an illustra- 
tive client computer, such as client PC 10, within environ- 
ment 5 shown in FIGS. 1 and 2A; 

FIG. 4 depicts the correct alignment of the drawing sheets 
for FIGS. 4Aand 4B; 

RGS. 4A and 4B collectively depict, at a high-level, 
sequential message flow involving client PC 10 and various 
illustrative network servers 50 and 410 for network booting 
the client PC, in accordance with my present invention, and 
various states of the client PC along with simultaneously 
occurring operational status while being so booted; 

FIG. 5A depicts an illustrative listing for BOOTPTAB file 
500 that resides within server 50 and is used during network 
booting of client PC 10; 

FIG. 5B depicts an illustrative listing for LANHD.INI file 
550 that resides within server 50 and is also used during 
network booting of client PC ID; 

FIG. 6 depicts a high-level block diagram of various 
software processes, including LANHDVSD.VXD proce- 
dure 245, that, in accordance with the present invention, 
collectively network boot client PC 10; 

FIG. 7 depicts a start-up sequence of events, that occur in 
client PC 10 and in accordance with my present invention, 
to network boot a client operating system, and accompany- 
ing processing modes which occur during that sequence; 

FIG. 8 depicts a flowchart of Start-up Procedure 800 that 
executes within client PC 10 and specifically for properly 
starting execution of LANHDVSD.VXD procedure 245 
shown in FIG. 6; 

FIG. 9 depicts a flowchart of Real Mode Procedure 900 
that executes within client PC 10 and specifically Interrupt 
(I^^^) 13 Handier 623 shown in FIG. 6; 

FIG. 10 depicts a flowchart of Asynchronous Procedure: 
NDIS Check 1000 that executes within client PC 10 and 
specifically within LANHDVSD.VXD procedure 245 
shown in FIG. 6; 

FTG. 11 depicts a flowchart of Asynchronous Procedure: 
Protected Mode Helper 1100 that executes within client PC 
10 and specifically also within LANHDVSD.VXD proce- 
dure 245 shown in FIG. 6; 

FTG. 12 depicts a high-level block diagram of random 
access trivial file transfer protocol (RATFTP) server 1200 
that forms a part of my present invention; 

FIG. 13 depicts commands 1300 executed by RATFTP 
server 1200; and 

FIG. 14 depicts, at a high-level, sequential message flow 
that occurs between a client computer (such as a PC or 
workstation) and an RATFTP server to utilize RATFTP. 
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To facilitate understanding, identical reference numerals 
have been used, where possible, to designate identical 
elements that are common to various figures. 

DETAILED DESCRIPTION 

After considering the following description, those skilled 
in the art will clearly realize that the teachings of the present 
invention can be readily utilized in conjunction with many 
different computer operating systems to provide network 
booting of any such 0/S to a client computer. Nevertheless, 
to simplify the ensuing description, 1 will discuss my inven- 
tion in the illustrative context of use with remotely instaUing 
and booting the Windows 95 0/S on a client computer in a 
client-server environment, where the client computer is 
illustratively a personal computer (PC). For ease of 
reference, this PC will be referred to hereinafter as a "client 

In this context, FIG. 1 depicts a high-level simplified 
block diagram of client-server environment 5 in which client 
PC 10 is to be booted through server 50. As shown, client PC 
10 is connected, via links 20 and 40, and network 30, to 
network server 50. Inasmuch as the particular implementa- 
tion and architecture of network 30 are both irrelevant, the. 
ensuing discussion will omit all such details. Through the 
present invention, a complete image of the Windows 95 0/S 
that is to execute on client PC 10 is stored as image 56 on 
hard disk 54 within memory 52 of server 50. 

In operation, whenever a user energizes (powers-up) \ 
client PC 10, this PC then establishes a network connection \ 
to the server and issues a boot request, as symbolized by line \ 
62, to the server. In response to this request, as symbolized 
by line 64, the server downloads sufBdent files from the 
stored client 0/S image to the client PC to permit the chent 
to boot the 0/S and continue loading the required 0/S files 
from the server 

In accordance with the inventive teachings, to facilitate 
reliable network booting of, e.g., a 32-bit client 0/S, such as 
Windows 95 0/S, the server implements sector-by-sector 
hard disk emulation of a local hard disk on the client PC. The 
server stores an image of a client hard disk, including the 
0/S and desired applications. Rather than directing each 
request that arises during booting of the client 0/S, for a 
specific sector of a stored file, to a local hard disk on the 
client, my inventive transport driver, which is downloaded 
and installed on the client as part of the client 0/S, redirects 
that request to the server to retrieve and download that 
sector, from the client hard disk image, to the client PC. As. 
a result, the source of the sectors remains transparent to the 
0/S, i.e., the client O/S is unaware that it is being booted 
from a network connection in lieu of a local hard disk drive. 
To provide reliable network booting, the inventive technique 
advantageously provides seamless and continuous client 
hard disk emulation throughout the entire boot process even 
though, during this process, various 0/S files are down- 
loaded and 0/S processes, such as a Windows 95 network 
driver, are activated which collectively change the process- 
ing mode of the client PC from real to protected and which 
reset and gain control of a network (e.g., LAN) adapter in the 
client PC. 

Once a processing mode is changed by the Windows 95 
0/S to protected from real, that 0/S would isolate a local 
hard disk from being directly read- or write-accessed outside 
of the 0/S. ConventionaUy speaking and in the absence of 
using the inventive teachings, this mode change would 
frustrate continued server-based client hard disk emulation. 
Also, once the Windows 95 0/S gains control, i.e.. 
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"ownership", of ihe network adapter, no process external to be remotely booted from the network and a directory on thai 
the 0/S could then gain direct access to that adapter. server in which the image file is located. In particular, as 
Consequently, again in the absence of using the inventive shown in FIG. 5B and discussed below, the LANHD.INI file 
teachings, this too would frustrate continued server-based contains a series of entries, with each entry specifying a 

client hard disk emulation. As will be seen, my present 5 different MAC address, a con:esponding server IP address 
invention advantageously overcomes both of these conven- therefor and a directory name. Once remote booting 
tional limitations. commences, server 50 downloads, through client hard disk 

FIG. 2A depicts a block diagram of environment 5 emulation on a sector-by-sector basis and as symbolized by 
showing, in additional detail, various elements of my present dashed line 260, image file 56^ to client PC 10 in order to 

invention. 10 remotely boot that client PC, The sequential operations that 

As shown, client PC 10 contains LAN adapter (also effectuate remote booting will be discussed below first in 
commonly referred to as a network interface card — ^NIC) conjunction with FIG. 4. ^ 
360. Each such NIC carries a unique physical hardware readily permit centralized client software 

address, referred to as a media access control (MAC) administration, environment 5 also includes administrative 

address, through which that card can be uniquely addressed 15 pc 210 (which is substantially, if not totally, identical in 
on a network. An illustrative MAC address is architecture to client PC 10), which is connected, via link 
"00A024Baf9a5". Each NIC also contains internal read only 215, to network 30. Once an administrator stationed at the 
memory 362 that stores boot code 364, which contains a administrative PC estabHshes a networked connection to 
BootP client process. Though this code is usually stored server 50 and has appropriate security and file access 

within the NIC, as shown here, this code could alternatively 20 permissions set on the server, that administrator can access, 
be implemented within a PC ROM BIOS (basic input output ^s symbolized by long-short dashed line 270, on a read and 
system) located on a motherboard of the client PC. With the ^^^^ ^^sis, the chent PC hard disk image files, such as, e.g., 
boot code stored in the NIC, as shown, and read into 56^, stored on the server. As a result, the administrator 

memory of the PC on power-up and executed, the client PC j^e ability, as desired and from one location, to open, 

establishes a network connection, through network 30 and 25 copy, update and change the contents of any client PC image 
connections 20 and 40, with remote server 50 for remotely s^Q^ed on server 50 remotely from its associated chent 

booting of the chent PC. Server 50 contains, to the extent pc ^nd without a need for that client PC to be energized. By 
relevant to the present invention, TCP (transmission control providing such centralized client software administration for 
protocol) servers 230, specifically: either BootP server 232 networked chents (of which only chent PC 10 is shown 

or DHCP (dynamic host configuration protocol) server 234, 30 piG. 2A for simplicity), use of the present invention i 
random access tnvial file transfer protocol should markedly reduce administrative cost, particularly in { 
(RATFTP) server 236. The BootP and DHCP servers are ^g^ge eateiprise environments. -J 
conventional in nature and, as such, will not be discussed in * c^y j *u .-^ • i 

J . -1 i-. *u La *u nATiTTTi u-1 A client PC image file need not be restricted to a single file 

anv detail. On the other hand, the RATFTP server, while , , ■ 1 . l j j- i • j • ^1 u 

aiij u^vaii. wii luv 1 " i\ • • , that contains a compkte hard disk image and IS accessiblc by 

based on and extends capabilities of a conventional tnvial 35 • <^ - * ^ i- * t *i. * j t-to 1 a -a - / 

ay , c .1 /rTJr™\ • J- -J 1 just its associated chent PC. In that regard, FIG. 2A depicts 

file transfer protocol (IMP) server, accesses individual ^ , . , c v ^ ^ a a- \. - fii 

, . , . / \ / .1- • * 1 . fii A an alternate embodiment of client hard disk image files 

desired sector(s) (rather than just a complete file as does a , , =■« ti r * j - i • * ■ 

, ,^/,,>„ V , J J. 1 * A ^u- stored on server 50. Here, chent disk images 562 contam 

conventional TFTP server), on hard disk 54 situated within ^ . ^, Jo/\ • * j- * • a 

.1. r V . u J J- 1 1*- o L. chent specific image files 280, in separate directones, and a 

server 50 — thus facilitating client hard disk emulation. Such u j i- *i-i/o£:i it 

T.I J jj ijj'^ directory containmg single shared client 0/S files 290. Here, 

sectors are specified by a boot loader and downloaded into 40 i. i- . • j- * * ^1 

. J • . 1 L . each chent image directory stores files unique to a corre- 

client PC during the network boot process^ ^^J^^ ^^^^ ^ ^ ^^^^^j^ ^^^^^^ 

In addition to TCP seivers 230, server 50 also stores on ^^^^^^^ 280,, .... 280„ store files for client PCs 1, ... , 
hard disk 54, a directory containing client PC hard disk ^_ respectively, which arc downloaded during the boot 
image 56 . This image contains aU 0/S flies 240 and process or accessed thereafter. Each such directory thus has 

accompanying user application files that we to execute on 45 ^ j.j correspondence, as symbolized by lines 285, with its 
clientPC 10. The O/S files include LANHDVSD.VXD file ,o„esponding client PC. In contrast, shared directoiy 290 
245. This file, which will be discussed in considerable detail ^^^^^^^ ^^^^ ^ LANHDVSD.VXD file 245, that are 
below, when executed during start-up of the client PC. ^^^^^^ ^j, ^^^^j^i bootable networked PCs. Hence, 
essentially permits thedient hard disk to be remote y j^^^^j 290 has a l;n correspondence, as symbolized by 

emulated through RATFTP server 236 and so as to remotely 50 295. between it and all n remotely bootable client PCs. 
boot the client 0/S from client PC hard disk image 56, and „ ^ , . , • r^/^o -ia j-iti 

advantageously in a manner that seamlessly pemiit^ the Between these two extremes shown in FIGS. 2A and 2B, 
emulation (and remote booting) to continue: (a) during and ^l^^^' specifically the underlying files, could be 

aftertheprocessingmodeoftheclientPCswitchesfromreal ^•"'^'^ across other sen/er-based file structures depending 

to protected; and (b) after the 0/S, as it boots, Ukes over 55 upon, e.g., which specdic client PCs and the number of such 
ownership of NIC 360. In addition to the client image file, P^s that are to share files, and Uie specific files that either are 
the server also stores, on hard disk 54, LANHD.IMG file '° ^^^'^ °' ^^^^^ '^^'"^ 
250 and initialization file 255, i.e., file LANHD.INI. The FIG- 3 depicts a high-level block diagram of client PC 10. 
LANHD.IMG file contains code that properly interprets As shown, client PC 10 comprises input interfaces (l/F) 

Interrupt 13 calls in the client PC for hard disk accesses 60 310, processor 320, NIC 360, memory 330 emd output 
during an initial boot process, i.e., prior to availability of interfaces 340, all conventionally interconnected by bus 350. 
network support through client 0/S. The LANHDJNl file Memory 330, which generally includes different modalities, 
stores initialization information required for remote booting. includes illustratively random access memory (RAM) 332 
This information specifies a corresponding network server, for temporary data and instruction store, diskette drive(s) 

in terms of ils IP (Internet protocol) address on the network, 65 (not specifically shown) for exchanging information, as per 
which stores a client hard disk image file for each of a group user command, with floppy diskettes, and non-volatile mass 
of client PCs (if not all such remotely bootable PCs) that can store 335 that is implemented through hard disk drive(s) 
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334, typically magnetic in nature. Should client PC 10 be 
implemented by "diskless" computer, then all disk drives, 
including both floppy diskette drive(s) and hard disk drive(s) 
334, would be omitted. Regardless of whether client PC 10 
contained a hard disk drive or not, the client 0/S, during its 5 
boot process, would be downloaded into RAM 332 and 
executed therefrom. As shown above in FIG. 2A, NIC 360 
contains internal read-only memory 362, that stores network 
boot code 364. This code, as will be discussed shortly below, 
once downloaded into RAM 332 on power-up permits the lO 
NIC to establish a network connection to a remote server. 

Incoming information can arise from two illustrative 
external sources: network supplied information, such as, in 
the context of network booting, sectorized information from 
a client hard disk emulation process executing in a network 15 
server, through network connection 20 to NIC 360, or other 
information from a dedicated input source — should it be 
connected, via path 305, to input interfaces 310. Since such 
a dedicated input source is not relevant here, it will not be 
discussed in any further detail. Saifl&ce it to say that input 
interfaces 310 contain appropriate circuitry to provide nec- 
essary and corresponding electrical connections required to 
physically connect and interface each differing dedicated 
input source to client PC 10. 

Input interfaces 310 also electrically connect and interface 
user input device 315, such as a keyboard and mouse, to 
client PC 10. Display 344, such as a conventional color 
monitor, and printer 348, such as a conventional laser 
printer, are connected, via leads 342 and 346, respectively, 
to output interfaces 340. The output interfaces provide 
requisite circuitry to electrically connect and interface the 
display and printer to the client PC. 

Furthermore, since the specific hardware components of 
client PC 10 as well as all aspects of the software stored 
within memory 330, apart from the modules that implement 
the present invention, are conventional and well-known, 
they will not be discussed in any further detail. Generally 
speaking, the network server, such as server 50 (shown in 
FIGS. 1 and 2) has an architecture that, at a high-level, is 
quite similar to that of client PC 10. 

1 will now discuss, at a high level, the sequential message 
flow that occurs, in accordance with my present invention, 
between client PC 10 and the network to remotely boot this 
client. FIGS. 4A and 4B collectively depict this message 45 
flow, involving client PC 10 and illustrative network servers 
50 and 410; the correct alignment of these figures is shown 
in FIG. 4. FIGS. 4A and 4B also depict the operational states 
and status of the client PC during its remote booting. Since 
this discussion will also refer to BOOTPTAB file 500 and 50 
LANHD.INI file 550 which are respectively and illustra- 
tively shown in FIGS. 5A and 5B, then, for ease of 
understanding, the reader should simultaneously refer to 
FIGS. 4A, 4B, 5 A and 5B throughout the following discus- 
sion. 55 

Once a user has powered-up client PC 10, as symbolized 
by block 420, the stored ROM BIOS in the client PC is 
loaded into RAM 332 (see FIG. 3) of the client PC from 
which that code is then executed by the PC. This operational 
mode is denoted by block 425 shown in FIGS. 4A and 4B. 60 
At this point, as symbolized by block 430, the client PC is 
not aware of its IP address. The client PC then reads the boot 
code fi-om a ROM situated on the NIC (or alternatively on 
the motherboard of the client PC itself) into RAM 332 and 
then executes that code — this operational mode denoted by 65 
block 450. In response to this code, the client PC wDl 
broadcast, as symbolized by line 432, a BootP (or DHCP) 



request packet over the network to elicit a response from a 
BootP (or DHCP) server. Illustratively, server 50 contains 
BootP server 232. This packet contains the hardware address 
of the NIC. For exemplary purposes, I will assume that 
address is "00A024Baf9a5". BootP server 232, which is a 
conventional TCP server, permits a network device, such as 
the NIC, to obtain its own IP address (i.e., here an IP address 
assigned to client PC 10), the name of a boot file to 
download, an IP address of a network server (here server 50) 
on which that boot file is located, and (where appropriate) an 
IP address of a default router. BootP server 232 does not 
download the boot file itself; that occurs, as will be shortly 
seen by TFTP server 402 executing within server 50. The IP 
address of the device can also be obtained through a DHCP 
request packet. DHCP is a newer protocol than BootP, and 
builds on and replaces BootP. Inasmuch as the BootP and 
DHCP protocols are conventional and well-known, I will not 
discuss them in any further detail. In that regard, for further 
information, the reader is referred to Chapter 19, "Booting 
Internet Hosts with BootP and TFTP" on pages 343-359 of 
P. Miller, TCP/IP Explained (©1997, Digital Press)— 
hereinafter the "Miller" text; and Chapter 16, "BOOTP: 
Bootstrap ProtocoP' on pages 215-222 of W. R. Stevens, 
TCP/IP Illustrated, Volume 1—The Protocols (©1994, 
Addison-Weslcy Inc.). Both of these chapters are incorpo- 
rated by reference herein. Since, for purposes of the present 
invention, either the BootP or DHCP protocols can be used 
with identical results, then, to simplify the ensuing 
discussion, I will omit any further reference to use of the 
DHCP protocol. The BootP server utilizes BOOTPTAB file 
500. This file, illustratively shown in FIG. 5 A, contains an 
entry for each of a number of remotely bootable devices that 
can connect to the network. Each such entry, such as entry 
520 within entries 510, specifies for a single associated 
device: a hardware address (ha), i.e., a MAC, for that device; 
an associated boot file (bf) for that device; a home directory 
(hd) on that server which contains the boot file; and an IP 
address (ip) to assign to that device. For ease of access, the 
boot file and home directory reside 00 the same server as the 
BOOTPTAB file, here server 50. While the network may 
contain multiple BootP servers (of which, for simplicity, 
only one of which is shown in FIGS, 4A and 4B), each 
remotely bootable device, such as a given NIC, has only one 
unique corresponding entry in only one BOOTPTAB file. In 
this manner, a broadcast BootP request appearing on the 
network from a given device will engender only one 
response from a single server that has an entry, in its 
BOOTPTAB file, that contains a MAC matching that con- 
tained in the request. 

In response to the BootP request packet, server 50 (also 
denoted as server 1), specifically BootP server 232 therein, 
will issue, as symbolized by line 436, a BootP reply packet 
onto the network. In particular, the BootP server will search 
through BOOTPTAB file 500 to locate an entry containing 
a MAC that matches that in the BootP request packet. If a 
match is found, as is the case for server 50, then BootP 
server 232 will issue the BootP reply packet. This reply 
packet will contain, from the parameters specified in the 
entry located in the BOOTPTAB file (only one such entry is 
illustratively shown in FIGS. 4A and 4B), an IP address 
assigned by the BootP server to client PC 10 (here 
132.147.001 .006), an IP address of server 50 (this IP address 
not being specifically shown in the entry) at which the boot 
file can be accessed, and a complete path on the server to the 
boot file (here \LANHD\LANHD.IMG). The boot file, here 
illustratively boot file 250 named LANHD.IMG, contains 
real-mode client hard disk emulation code as well as a name 
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of an initialization file to be accessed. The initialization file, 
specifically LANHD.I^^, specifies a full path, including a 
file name, of a client image file and a network server on 
which that file is stored. For illustrative purposes, the client 
image for client PC 10 is shown as being stored on network 
server 410 (also denoted as server 2) which is different from 
that (server 50) storing the boot file. In other situations, these 
two network servers could be the same. 

In any event, after the client PC appropriately processes 
the BootP reply, the client PC will then know, as symbolized 
by block 440, its IP address. Next, as symbolized by line 
442, the PC will issue, through the NIC. a TFTP request 
(typically a TFTP read command) to server 50, specifically 
TFTP server 402 thereon, to download the boot file identi- 
fied in the BootP reply packet. If the TFTP server can locate 
and open this file based on the information provided in the 
TFTP request, then, as symbolized by line 444, TEvTP server 
402 will download the boot file to client PC 10. Once the 
boot file has been completely downloaded into RAM 332 
(see FIG. 3) on client PC 10, this PC will acknowledge a 
successful download by issuing, as symbolized by line 446 
shown in FIGS. 4A and 43, a TFTP acknowledgement 
(ACK) packet, back to server 50. With the boot file 
(LANHD.IMG) residing, as symbolized by block 460, in the 
chent PC and after the ACK packet is issued, the client PC 
will begin executing the boot file from RAM 332 to imple- 
ment client hard disk emulation. At this point, client PC 10 
begins operating, as symbolized by block 470, under control 
of the downloaded boot file (LANHD.IMG) and ceases 
operating under the ROM boot code previously downloaded 
from, e.g., the NIC. 

The boot file, early in its execution, will caiise the client 
PC to issue -a-TFPT request, as symbohzed by line 462, 
back to server 50 to download an initialization file, specifi- 
cally LANHD.INI file 550. This initialization file, as shown 
in FIG. 5B, also contains a series of entries. Here, each such 
entry, of which entry 560 is typical, contains a MAC, an IP 
address of a server that stores a client image file for the 
device having that MAC and a complete path to the client 
image file (here file 414 on server 410) on that server. A 
LANHD.INI file entry also contains an illustrative term, 
such as "3c90x" or "3c5x9", which merely describes a name 
of the NIC associated with that entry and is ignored, as a 
comment field, during subsequent processing of this file by 
the client PC. A further parameter (db) in entry 560 defines 
a default boot option (illustratively set to A or C) which is 
not relevant here. Once the download, as symbolized by line 
464, completes, client PC 10 will then generate and transmit, 
as symbolized by line 466, a TFTP ACK packet, over the 
network back to server 50. Furthermore, once this file has 
been downloaded, the client PC, under control of the boot 
file, LANHD.IMG, will process this file by first checking the 
contents of this file to determine whether an entry in the file 
contains a MAC that matches that of the NIC in the client 
PC. When an entry having a matching MAC is found, as 
illustratively occurs here, the boot file will then extract, from 
that entry, the full path to the client image file (here C: 
\LANHD\diskl50) and the IP address (here 
132.147.001.001) of a network server (here server 410) on 
which the client image file resides. Once client PC 10 
obtains this information from the initialization file, the chent 
PC, specifically executing the boot file (LANHD.IMG) 
which is then performing client hard disk emulation, issues, 
as symbolized by line 475, an RATFTP request to network 
server 410 to download a boot sector from chent PC image 
file 414 residing thereon. 

In response to the RATFTP request, RATFTP server 412 
executing on network server 410 downloads the boot sector 



from the chent PC image file to client PC 10 and specifically 
into RAM 332 (see FIG. 3) on that PC. Once this boot sector 
is completely downloaded into RAM, the client PC then, as 
symbolized by block 480, executes it. Under control of the 

5 boot sector, various remaining files of the 32-bit client PC 
0/S are downloaded in sequence and their execution started 
in order to initiate associated 0/S processes and, by doing 
so, complete the start-up of the client 0/S on PC 10. Such 
downloading occurs on a sector-by-sector basis through 
corresponding RATFTP read operations. In addition, the 
cUent O/S can write information, also on a sector-by-sector 
basis (through client hard disk emulation), into its cUent 
image file through RATFTP write operations. These RAT- 
FTP operations are symbohzed by hne 484 and are preceded 
by a request, as symbolized by hne 482, to download/upload 

1^ information between server 410 and client PC 10. Each such 
RATFTP operation is acknowledged, as symbolized by Hne 
486, upon its completion, by the device that receives data, 
i.e., either the client PC or network server 410. From the 
point that the boot sector takes over control of the client PC, 

20 the PC is thereafter operated by the chent O/S, as symbol- 
ized by block 490, rather than by the boot file LANHD.IMG. 

FIG. 6 depicts a high-level block diagram of various 
software processes, including LANHDVSD.YXD proce- 
dure 245, which executing in the chent PC collectively 

25 network boot that PC. To fully appreciate the interaction of 
these procedures, the reader should also simultaneously 
refer throughout the following discussion to FIG. 7 which 
shows basic start-up sequence 710 that occurs within the 
chent PC for implementing network booting and the asso- 
ciated processing modes 750 that simultaneously occur in 
that PC, 

During network booting, the client PC initially operates in 
a real processing mode and then, based on the client 0/S 
processes then initiating, transitions to a protected process- 

35 ing mode. LANHDVSD.VXD procedure 245 permits chent 
PC hard disk emulation to seamlessly continue while the 
processing modes change during 0/S booting as well as after 
the client 0/S takes ownership of the NIC in the cUenl PC. 
During the boot process and prior to the availability of any 

40 chent 0/S-based network support, client hard disk emulation 
occurs, as discussed above in conjunction with LAN- 
HD.IMG operation shown in FIGS. 4A and 4B, through 
appropriate calls made to Interrupt 13 (Int 13) handler 623. 
Through such calls, appropriate sectors in the chent image 

45 file are downloaded, via real-mode NIC driver 625 and Int 
13 Handler 623 to remotely install various components of 
0/S 690 into client PC. The actual client hard disk emulation 
process is provided through Real Mode Procedure 900 that 
executes as part of Int 13 Handler 623. In essence, procedure 

50 900 determines, based on values of status flags, whether the 
client O/S is then capable of handhng a network request for 
sector access of the client image file. If the client 0/S has not 
then progressed to that point in its boot process, procedure 
900 processes that request, in real mode, through Int 13, The 

55 remainder of this handler is conventional in nature. 

In particular, as shown in start-up sequence 710, upon 
power-up of the chent PC, this PC commences operation 
using real-mode processing, as symbohzed by line 752. This 
mode of operation persists through downloading and initia- 

60 tion of the boot loader and client hard disk emulation code, 
i.e., boot file LANHD.IMG; and commencement of loading 
32-bit client 0/S 690 (e.g., Windows 95 0/S). Here, chent 
hard disk emulation with sector-by-sector downloading is 
provided by block 620, specifically Int 13 Handler 623 and 

65 real-mode NIC driver 625. 

Once a file, e.g., Windows 95 file "Win.com", which loads 
the kernel of the client 0/S (i.e., Windows 95 file 
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" VMM32. VXD") has fully loaded aad its execution has then 
been initiated to actually load the 0/S kernel, the processing 
mode of the client PC begins transitioning between real and 
protected, and continues, as symbolized by line 754, in this 
transitory state until an Input/Output sub-system (I OS) com- 
ponent within the client 0/S has itself initialized. Once this 
kernel is installed by file "Win.com" and initializes, the 
kernel then installs and activates various device drivers. 
LANHDVSD.VXD procedure 245 is one of these drivers. 
This procedure is compliant with both Int 13 Handler 623 
and with the 0/S, specifically a network driver (NDIS — 
network driver interface specification) kernel therein and the 
lOS, Procedure 245 assures that client hard disk emulation 
occurs either through the Int 13 Handler or the client 0/S, 
specifically an 0/S NDIS (network driver interface ^5 
specification) transport driver therein, based on the process- 
ing state and 0/S boot status of the client PC. As shown, 
procedure 245, which executes as a protected mode driver, 
contains start-up procedure 800, asynchronous procedures: 



state of the client-O/S permit, will service any subsequent 
Int 13 requests for hard disk access through the client 0/S, 
specifically NDIS. Thus, all subsequently accessed client 
image sectors, occurring in protected mode, will be accom- 
5 modated through lOS 680; 0/S -based network support 
block 640, specifically through lOS vendor supplied driver 
642, NDIS transport driver 655, NDIS kernel 660, and 
protccted-mode NIC driver 673; and NIC 360. Inasmuch as 
lOS 680, NDIS transport driver 655, NDIS kernel 660, lOS 
10 vendor supplied driver 642 and NIC drivers 625 and 673 are 
all conventional, I will not discuss these in any further detail. 

FIG. 8 depicts a flowchart of Start-up Procedure 800. As 
noted above, this procedure properly starts-up execution of 
LANHDVSD.VXD procedure 245 and its constituent pro- 
cesses. 

In particular, upon entry into procedure 800, execution 
first proceeds to decision block 810. This decision block, 
when executed, tests whether Int 13 Handler 623 has been 



NDIS check 1000 and Protected Mode Helper 1100, lOS 20 "^^^"^."i; ^'f. ^^""^^^^ ^"^'^ ^^^""^^^^^ ^^^"^ 



vendor supplied driver 642, and NDIS transport driver 655. 
The two asynchronous procedures collectively provide, in 
conjunction with Int 13 Handler 623, seamless client hard 
disk emulation during the real-protected transitory state. 
These asynchronous processes, through setting and testing 25 
appropriate flags (specifically "NDIS Loaded" and "Need 
Protected Mode Helper" flags, as discussed in detail below) 
used as processing state semaphores, collectively control the 
transition of hard disk requests to the networked client 
image from the Int 13 Handler to the client O/S depending 30 
upon, as the client 0/S is then booting, the 0/S resources 
that are then available. In that regard, when sufficient 0/S 
resources become available to permit network access 
through the client 0/S, then the asynchronous procedures 
permit these requests to be serviced by the NDIS and lOS 35 
components of the client O/S rather than by Int 13 Handler 
623. 

lOS vendor supplied driver 642 binds itself to one of the 
thirty-two abstraction layers situated within lOS 680. Once 



client PC hard disk emulation can not occur. Consequently, 
execution simply exits from procedure 800, via NO path 
813. Alternatively, if this handler is installed, then decision 
block 810 directs execution, via YES path 815, to block 820. 
This latter block inserts an entry, as a vendor suppHed driver, 
for procedure 245 into an appropriate layer in lOS 680. This 
entry, which will be specificaUy used by lOS vendor sup- 
plied driver 642 (as discussed above), is used as an entry 
point for client hard disk requests. Once this entry point has 
been created, then execution proceeds to block 830. This 
block, when executed, binds LANHDVSD.VXD procedure 
245, specifically NDIS transport driver 655 therein (see FIG. 
6), as a transport driver to NDIS kernel 660. Once this 
occurs, procedure 800 then executes block 840 which, in 
turn, starts Asynchronous Procedure: NDIS check 1000. 
Once this procedure 1000 is started, execution exits from 
start-up procedure 800. 

FIG. 9 depicts a flowchart of Real Mode Procedure 900 
that executes within the client PC and specifically within Int 



this occurs, driver 642 then appropriately handles client hard 40 handler 623. As noted above, procedure 900 determines. 



disk requests that originate with the O/S based on the 
processing mode of the client at the time: either by effec- 
tively invoking Int 13 Handler to process the request (for 
non-O/S supported network access) or sending the request to 
the NDIS processes in cUent O/S (for O/S supported net- 
work access). 

Specifically, once LANHDVSD.VXD procedure 245 is 
loaded during the real-protected transitory state, this proce- 
dure executes start-up procedure 800. Also, during this state, 



45 



based on values of status flags, whether the client 0/S is then 
capable of handling a network request for sector access of 
the client image file. If the client 0/S has not then progressed 
to that point in its boot process, procedure 900 processes that 
request, in real mode, through Int 13. 

In particular, procedure 900 executes at the occurrence of 
an Int 13 request for a client hard disk access. Such a request 
specifies a particular drive, sector, cylinder, head and buffer 
from which stored data is to be read. Upon entry into 



the client 0/S activates other drivers as well. One such 50 procedure 900, execution first proceeds to decision block 

driver is NDIS transport driver 655. This driver is a protocol 910. This block, when executed, determines whether an 

stack that communicates with the NIC through NDIS rather "NDIS Loaded" flag has been set to one, thereby signifying 

than directly (as occurs with the Int 13 Handler). Since a that the NDIS portion of the client 0/S has been loaded and 

finite period of time will be needed for an NDIS kernel and is active. If this portion either is not loaded or is not yet fully 

the NDIS transport driver to fully activate and this transport 55 activated, then decision block 910 routes execution, via NO 



driver to bind itself to the NDIS kernel and to lOS 680, 
start-up procedure 800 will launch Asynchronous Proce- 
dure: NDIS check 1000 (which will be discussed in detail 
below in conjunction with FIG. 10), In essence, once 
launched, NDIS check procedure 1000 then regularly deter- 
mines whether an NDIS kernel (here NDIS kernel 660) of 
the client 0/S is then executing. If it is executing, the client 
O/S will have already switched to the protected mode. 
Hence, procedure 1000 sets an appropriate status flag to 



path 913, to block 920. This latter block, when executed, 
attempts to service the hard disk request through the Int 13 
Handler Thereafter, execution proceeds to decision block 
930 to test whether this attempt was successful. If the 
60 request has been successfully serviced over the network 
through the Int 13 Handler, i.e., the request did not fail, then 
execution exits from procedure 900, via NO path 933, with 
the results of that request then being returned. 
Alternatively, if the request failed, then decision block 



signify that the O/S has entered this mode, as symbolized by 65 930 routes execution, via YES path 935, to decision block 
line 756, and launches Asynchronous Procedure: Protected 940. This latter decision block also tests the status of the 
Mode Helper 1100. This latter procedure, should the current "NDIS Loaded" flag to determine whether the NDIS portion 
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of the client 0/S has aow been loaded and is now active. If procedure, should the current state of the client 0/S then 

the NDIS portion either has not been loaded or is not fully being booted permit, will service any subsequent Int 13 

active, then execution is fed back, via NO path 943, back to requests for hard disk access through the client 0/S, spc- 

this decision block to await availability of the NDIS portion. cifically NDIS. 

If, however, the NDIS portion is loaded and active, then 5 In particular, upon entry into procedure 1100, execution 

decision block 940 routes execution, via YES path 945, to will first proceed to block 1110. This block merely waits for 

block 950. This latter block sets the value of a "Need a finite interval of time, typically less than the I/O timeout 

Protected Mode Helper" flag to one. Execution is also interval for the Int 13 Handler, to elapse — here to permit the 

directed to block 950 in the event decision block 910 "Need Protected Mode Helper" flag to be set by Real Mode 

determined that the value of the "NDIS Loaded" flag is set Procedure 900. Once this interval has elapsed, execution 

to one, i.e., the NDIS portion is fully active upon entry into then proceeds to decision block 1120. This block determines 

procedure 900. Setting the "Need Protected Mode Helper" whether the cUent 0/S has issued an lOS request for the 

flag to one at fliis point indicates that although an Int 13 current access request. If this request has been issued, then 

request IS pending, that request requires protected mode execution exits, via YES path 1123, from procedure 1100 

processing. Such a need can anse where at ihc tmie the ^^^^ ^^at this request can be processed through the client 

request was issued insufficient NDIS resources were active, ^ ecificall >fDIS 

but subsequently and before the request was handled, those . . , . . . 

resources became active (by virtue of various NDIS pro- AltemaUvely, if an lOS request has not been issued for the 

cesses having been started, bound and initialized in the ^^^^^^ access request, then decision block 1120 routes 

interim). Once block 950 sets the value of the "Need execution, via NO path 1125, to decision block 1130. This 

Protected Mode Helper" flag, execution proceeds to decision 20 letter decision block, when executed, tests whether the 

block 960. This latter block tests whether this flag (serving "Need Protected Mode Helper" flag is set to one. If this flag 

as a semaphore) has been reset to zero by another procedure, has been so set, such as through real mode procedure 900, 

i.e.. Asynchronous Procedure: Protected Mode Helper 1100, this indicates that O/S boot has sufficiently progressed to the 

thereby signifying that real mode client hard disk emulation point where client hard disk emulation needs to occur on a 

iscurrentlyrequired.Aslongasthe value of the flag remains 25 protected mode basis with O/S support through LANHD- 

at one, indicating that protected mode hard disk emulation is VSD.VXD. In this instance, decision block 1130 will route 

to occur through LANHDVSD.VXD, execution will loop execution, via YES path 1133, to block 1140. This latter 

back to the decision block to effectively poU this flag, on a block, when executed, will service the pending Int 13 

routine basis, until its value changes. Alternatively, if the request via a RATFTP call through NDIS, effectively pro- 

value of the flag is set to zero, hence indicating that real 30 viding O/S supported network access. Such an Int 13 request 

mode disk emulation is needed to handle the current Int 13 would be pending at this point inasmuch as this flag would 

request, then execution exits, via YES path 965, from have been previously set to one by Real Mode Procedure 

procedure 900 with results of that request, as produced by 900 in response to such a request and if either the NDIS 

the Int 13 Handler, then being obtained and returned. portions of the client O/S, were, during execution of proce- 

FIG. 10 depicts a flowchart of Asynchronous Procedure: 35 dure 900, not sufficiently active, or became sufficiently 

NDIS Check 1000. As noted above, this procedure, once active after routine 900 was just entered. As discussed 

launched, regularly determines whether an NDIS kernel of above, if the "Need Protected Mode Helper" flag is set to 

the client O/S is then executing and hence whether the client one, this indicates that although an Int 13 request is now 

0/S has switched to the protected mode. If the NDIS kernel pending, that request requires protected mode processing, 

is executing, then this procedure sets the "NDIS Loaded" 49 Such a need can arise where at the time the request was 

flag, to signify that this 0/S state, and launches Asynchro- issued insufficient NDIS resources were active, but subse- 

nous Procedure: Protected Mode Helper 1100. quently and before the request was handled, those resources 

In particular, upon entry into procedure 1000, execution became active (by virtue of various NDIS processes having 

first proceeds to block 1010. This block merely waits for a been started, bound and initialized in the interim), 

finite interval of time, typically less than a I/O timeout 45 Thereafter, once this Int 13 request is processed, via execu- 

interval for the Int 13 Handler, to elapse. This interval is tion of block 1140 and through NDIS, execution proceeds to 

usually sufficiently long to permit the NDIS kernel and the block 1150 which, in turn, resets the value of the "Need 

NDIS transport driver to fully initialize as weU as for this Protected Mode Helper" flag to zero. Doing so precludes any 

transport driver to bind itself to the NDIS kernel and to the processing of further Int 13 requests through NDIS. Once 

lOS. Once this interval has elapsed, execution then proceeds 50 block 1150 completes its execution, execution is directed, 

to block 1020. This block attempts to open the LAN adapter via paths 1155 and 1160 back to block 1110 to await a next 

(NIC 360) via the NDIS kernel in order to effectuate a client lOS request, and so forth. Execution is also directed to path 

0/S supported network access. Once this attempt is made, 1160, via NO path 1135, in the event decision block U30 

decision block 1030 tests whether this attempt was success- determines that the "Need Protected Mode Helper** flag is 

ful. If this attempt was not successful, i.e., appropriate NDIS ss zero. 

resources were not then available to facilitate such a network As discussed above, my inventive RATFTP server resides 

access, then decision block 1030 merely routes execution, on the network server which stores the client PC image file, 

via NO path 1033, back to block 1010, and so forth. The RATFTP (random access trivial file transfer protocol) 

Alternatively, if this attempt succeeded, then decision block server permits that image file to be accessed on a random 

1030 routes execution, via YES path 1035, to block 1040. 60 access sectorized basis as would be required by the cHent 

This latter block sets the value of "NDIS Loaded" flag to 0/S if that client were to be booted from its local hard disk, 

one. Thereafter, execution proceeds to block 1050 which, in FIG. 12 depicts a high-level block diagram of RATFTP 

turn, starts Asynchronous Procedure: Protected Mode server 1200. This server is formed of command interpreter 

Helper 1100. Once this asynchronous procedure starts, 1210 which executes RATFTP commands against file store 

execution exits from procedure 1000. 65 1220. In particular, incoming commands bearing a pre- 

FIG. 11 depicts a flowchart of Asynchronous Procedure: defined IP port number associated with this server are routed 

Protected Mode Helper 1100. As noted above, this to this server. The server, in turn, then executes those 
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commands to Open a desired file Stored on the file server and download it, via a READ DATA message to the client 

then execute a read and/or write operation to any sector of workstation. Alternatively, upon receipt of a RAW 

that file. command, the RATFTP server will then access the desired 

The RATFTP server I have invented modifies and extends ^^^^^^ ^P^«!^ ^ sector, contained in a WRITE DATA 
a conventional TFTP (trivial file transfer protocol) server. In 5 messageemanating from the client computer to the RATFTP 

that regard, a conventional TFTP server (note server 402 s^^^; .^f READ DATA and WRITE DATA messages are 

u ' T^rr^c Aj< ji An\ '^ * -i/:! collectively symbolized by hne 1434 with data now for a 

shown m F GS 4A and 4B) implements a simple file ^^^^ ^^^^ client workstation indicated by a solid 

transfer m.lity for downloading an entire file stored on a ^^^^head, and with data flow for a RAW command to the 

networked file server, via a TCP/IP connection, to a net- ratFTP server indicated by a dashed arrowhead. Once the 

worked client as weU as uploadine a complete nle, over that -^^ j ♦ • • * i j i j j • * 4U r * nr^ 

*^ , ^, data is appropriately downloaded into the client PC or 

connection, from the chent to the file server. ;r,t« tu^ d attittj «^ 

' uploaaea into the KAlrlr server, that device issues, as 

However and to the extent relevant here, a TFTP server symbolized by line 1436, an appropriate READ or WRITE 

will only download or upload a complete file— but not any aCK message back to the originator of the data. Message 

portion of t he file let alone a given sector of that file. flow for a READ ACK to the RATFTP server is indicated by 

Inasmuch as TFTP is well known, I will omit any details of a soUd arrowhead; message flow for a WRITE ACK to the 

TFTP and instead refer the reader to Chapter 19 of the Miller client computer is indicated by a dashed arrowhead. Mes- 

text for further details. sages 1434 and 1436 are repealed for each successive sector 

The commands implemented by my inventive RATFTP to be downloaded or uploaded in a group of successive 

server are depicted in FIG. 13 by command block 1300. In sectors. Block 1430 is itself repeated for each different group 

addition to conventional file read (R) and file write (W) of sectors in a common file. At the end of a session, typically 

commands 1340 and 1350, respectively, as would be imple- after a session timeout of, e.g., thirty seconds, an RATFTP 

mented on a TFTP server, the RATFTP server also imple- CLOSE operation, symbolized by dashed line 1450, occurs 

ments random access read (RAR) and random access write at the RATFTP server to close the file. Hence, an actual 

(RAW) commands 1320 and 1330 to implement a read and CLOSE command does not need to be issued by the client 

write operation, respectively, to any sector(s) of a desired computer. This timeout value could be changed for a given 

file. In response to RATFTP OPEN command 1310, the file, as needed, based, e.g., on the number of cUent com- 

RATFTP server opens a file and keeps the file open for a puters then accessing that file or could specified by, e.g., a 

duration of session. This, in turn, eliminates a need to client as an initialization value in the LANHD JNI file for 

successively re -open a file each time a different sector is read that client. 

from or written into that file. CLOSE command 1360, being By virtue of downloading desired physical sectors of a 

implicit in RATFTP server operation, closes a open file then client PC hard disk image file from a network server to a 

being accessed (read or written) at the end of a session client computer, hence operating at a physical level of the 

(typically at a session timeout), rather than, as in a conven- disk itself, the present invention is independent of and will 

tional TFTP server, at an end of a file (EOF) condition. properly operate with substantially any client file system, 

With the above in mind regarding my inventive RATFTP whether it is, e.g., FAT, FAT32, HPFS or NTFS. 

server, FIG. 14 depicts, at a high-level, sequential message Furthermore, though I have described my invention in 

flow that occurs between a client computer (such as a PC or conjunction with use with Windows 95 0/S, those skilled in 

workstation) and an RAFFTP server to utilize RATFTP. the art wiU reahze that the teachings of my invention are 

In particular, a client computer would first issue an 40 applicable to use with nearly any client 0/S, such as, e.g., 

RATFTP OPEN command, as symbohzed by line 1410, to ^2-bit operaUng systems, to seamlessly emulate a local hard 

a network server executing an RATFTP server. This com- disk and perform network booting while that 0/S, during its 

mand would contain various session parameters including a boot process, transitions from real to protected processing 

name of a given file resident on the network server. Once the n^ode and/or gains ownership of a network adapter in the 
RATFTP server received and successfully opened the 45 client. 

desired file, that server would generate and send, as sym- Although a single embodiment and associated modifica- 

bolized by fine 1420, a RATFTP acknowledgement (ACK) tions which incorporate the teachings of my present inven- 

packet (or, if the operation was unsuccessful, a negative tion have been shown and described in detail herein, those 

acknowledgement — NACK — , over the network, back to the skilled in the art can readily devise many other embodiments 
chent PC. The OPEN command could fail if, e.g., the desired 50 and variants thereof that still utilize these teachings, 

file did not exist on the network server; or, based on the file I claim: 

attributes or permissions, the client PC was not permitted to LA method of booting an operating system (O/S) to a 

access that file. Now, assuming that the file was successfufly client computer from a network, the network storing an 

opened, messages 1430 would be repeated as often as image on a first server, the image having 0/S files for the 
needed to download or upload each group of successive 55 client computer, the method comprising the steps, in the 

sectors on the file between the client computer and the client computer, of: 

RATFTP server. As indicated within messages 1430, a client (a) issuing a corresponding request to the first server to 

computer, based on whether a random access sector read or download contents of a corresponding one of each of a 

random access sector write operation was desired, would plurality of sectors residing on the first server so as to 

generate a RATFTP RAR or RATFTP RAW message, with 60 form a plurahty of requests, wherein: 

ofiket and count parameter values therein. The offset param- (al) said sectors collectively store an image file which 

eter specifies, on a relative basis from the start of the file, the contains the image; and 

first specific sector that is desired to be read or written. The (a2) the first server emulates, in response to said 

count parameter specifies the number (count) of successive pluraHty of requests, behavior of a disk drive on the 

sectors (if any), after the first sector, that is also to be read 65 chent computer such that contents of individual 

or written as well. Upon receipt of a RAR command, the physical sectors of the image file specified in corre- 

RATFTP server will then access the desired sector and spending ones of the requests are accessed by the 
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first server on a sector-by-sector basis from a disk 
drive associated with the first server and 
downloaded, via the network, to the client computer, 
and wherein the corresponding request issuing step 
comprises the steps of: 5 

(a3) generating a request, to the first server, to down- 
load a boot sector contained in the image file; and 

(a4) executing the boot sector, once the boot sector is 
downloaded from the first server, so as to subse- 
quently generate each of said plurality of requests 
such that the client computer receives, on a sector- 
by-sector basis from the first server, the contents of 
the individual physical sectors that collectively com- 
prise client 0/S files; 

(b) storing the contents of each of said sectors received 
from the first server; and 

(c) activating client 0/S processes embodied by the 
contents of said sectors stored on the client computer, 

2. The method in claim 1 wherein said corresponding 
request issuing step, in the client computer, ftirther com- 
prises the step of: ^0 

obtaining, from a second server, an address of the image 
file stored on the first server. 

3. The method in claim 2 further comprising the step, in 
the client computer, of obtaining a boot file from a second 
network server, the boot file comprising real-mode client 25 
disk emulation code; and wherein the request generating 
step comprises the step of producing the boot sector down- 
load request through executing the boot file, wherein the 
boot sector request contains an identification of the first 
server and the name of the image file, 30 

4. The method in claim 3 wherein the first and second 
servers are the same server or different servers connected to 
the network. 

5. The method in claim 3 further comprising the step of 
providing the client disk emulation, on a sectorized basis, 
while a processing mode of the client computer changes 
from real to protected and the client 0/S takes ownership of 
a network interface situated in the client computer and 
connected to the network. 

6. The method in claim 5 further comprising the step, in 
the client computer, of: 

downloading, as part of the image file, a transport driver; 
and 

executing, as one of the client 0/S processes, the transport 
driver such that each of the client disk access requests, 45 
generated by the client computer while the client 0/S is 
being booted, is directed to the first server so as to 
retrieve contents of a corresponding sector of the image 
file stored on the first server in lieu of accessing a sector 
associated with a disk locally situated at the chent 
computer, whereby, through use of the transport driver 
and while the client 0/S is being booted, an actual 
source of the contents of the sectors remains transpar- 
ent to the client 0/S. 

7. The method in claim 6 wherein the transport driver 
execution step further comprising the steps of: 

while the client computer is operating in the real process- 
ing mode, handling client disk access operations 
through a real mode intermpt handler procedure so as 
to generate ones of the plurality of requests; 

while the client computer is operating in the protected 
mode, handling client disk access operations through 
pre-defined cfient 0/S network procedures so as to 
generate subsequent ones of the plurality of requests; 

detecting, as the client 0/S processes are being activated, 65 
a transition in the client processing mode from real to 
protected; and 



during the transition, controlling a changeover in handling 
client disk access operations from the real mode inter- 
rupt handling procedure to the client 0/S network 
procedures to generate said subsequent ones of the 
plurality of requests. 

8. The method in claim 7 wherein the controlling step 
comprises the step of controlling the changeover based on 
whether sufficient active resources then exist in client 0/S as 
it is booting. 

9. The method in claim 7 wherein the detecting step 
comprises the step of employing a semaphore-based proce- 
dure for detecting said transition in the client processing 
mode. 

10. The method in claim 7 further comprising the steps, in 
the client computer, of: 

executing predefined boot code stored in the client com- 
puter which, in response thereto, broadcasts a client IP 
(Internet protocol) request message on the network, 
said client IP request message containing an address of 
the network interface situated in the client computer; 

obtaining, from the second server, a reply message to the 
client IP request message, wherein the reply message 
contains an IP address assigned to the client computer, 
an IP address of the first server and an address of the 
boot file stored on the second server, wherein the boot 
file contains the real-mode client disk emulation code 
and a name of an initialization file; 

downloading the boot file from the second server; 

executing the emulation code contaiaed in the boot file, 
once it has been downloaded, so as to initiate real-mode 
client disk emulation through the second server and 
thereafter to download the initialization file from the 
second server, wherein the initialization file contains an 
address of the image file residing on the first server and 
an address of the first server; and 

downloading, from the first server and in response to 
execution of the boot file in conjunction with the 
initialization file, a boot sector contained within the 
image file; 

issuing, as a result of executing the boot sector, each of 
said plurality of requests, to the second server, to 
download the contents of the plurality of corresponding 
sectors that collectively store the image file; and 

starting execution of various client 0/S processes in the 
client computer as sufficient 0/S files are downloaded 
on a sector-by-sector basis from the image file stored on 
the first server. 

11. The method in claim 10 wherein the plurality of 
requests issuing step comprises the step of generating a 
separate random access trivial file transfer protocol 
(RATFTP) read request message to an RATFTP server in the 
first server in order to download a corresponding one of the 
sectors of the image file, wherein the RATFTP server 
implements sectorized access to the image file. 

12. The method in claim 10 wherein the controlling step 
comprises the step of controUing the changeover based on 
whether sufficient active resources then exist in client O/S as 
it is booting. 

13. The method in claim 10 wherein the detecting step 
comprises the step of employing a semaphore-based proce- 
dure for detecting said transition in the client processing 
mode. 

14. The method in claim 10 wherein the first and second 
servers are the same server or different servers connected to 
the network. 

15. The method in claim 5 further comprising the steps, in 
the client computer, of: 
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executing predefined boot code stored in the client com- 
puter which, in response thereto, broadcasts a client IP 
(Internet protocol) request message on the network, 
said client IP request message containing an address of 
the network interface situated in the client computer; 

obtaining, from the second server, a reply message to the 
cUent IP request message, wherein the reply message 
contains an IP address assigned to the client computer, 
an IP address of the first server and an address of the 
boot file stored on the second server, wherein the boot 
file contains the real-mode client disk emulation code 
and a name of an initialization file; 

downloading the boot file from the second server; 

executing the emulation code contained in the boot file, 
once it has been downloaded, so as to initiate real-mode 
client disk emulation through the second server and 
thereafter to download the initialization file from the 
second server, wherein the initialization file contains an 
address of the image file residing on the first server and 
an address of the first server; and 

downloading, from the first server and in response to 
execution of the boot file in conjunction with the 
initiahzation file, a boot sector contained within the 
image file; 

issuing, as a result of executing the boot sector, each of 
said plurality of requests, to the second server, to 
download the contents of the plurality of corresponding 
sectors that collectively store the image file; and 

starting execution of various client 0/S processes in the 
client computer as sufficient 0/S files are downloaded 
on a sector-by-sector basis from the image file stored on 
the first server. 

16. The method in claim 15 wherein the plurality of 
requests issuing step comprises the step of generating a 
separate random access trivial file transfer protocol 
(RATFTP) read request message to an RATFTP server in the 
first server in order to download a corresponding one of the 
sectors of the image file, wherein the RATFIT server 
implements sectorized access to the image file. 

17. The method in claim 15 wherein the first and second 
servers are the same server or different servers connected to 
the network. 

18. Apparatus for booting an operating system (0/S) to a 
cUent computer from a network, the network storing an 
image on a first server, the image having 0/S files for the 
client computer, the apparatus comprising a client computer 
having; 

(a) a processor; and 

(b) a memory, connected to the processor, for storing 
executable computer instructions therein; and 

(c) wherein the processor, in response to the instructions: 
(cl) issues a corresponding request to the first server to 

download contents of a corresponding one of each of 
a plurality of sectors residing on the first server so as 55 
to form a plurality of requests, wherein: 

(cla) said sectors collectively store an image file which 
contains the image; and 

(clb) the first server emulates, in response to said 
plurality of requests, behavior of a disk drive on the 60 
client computer such that contents of individual 
physical sectors of the image file specified in corre- 
sponding ones of the requests are accessed by the 
first server on a sector-by-sector basis from a disk 
drive associated with the first server and 
downloaded, via the network, to the client computer, 
and wherein the processor further: 



(clc) generates a request, to the first server, to down- 
load a boot sector contained in the image file; and 
(eld) executes the boot sector, once the boot sector is 
downloaded from the first server, so as to subse- 
quently generate each of said plurality of requests 
such that the client computer receives, on a sector- 
by-sector basis from the first server, the contents of 
the individual physical sectors that collectively com- 
prise client 0/S files; 
(c2) stores the contents of each of said sectors received 

from the first server; and 
(c3) activates client O/S processes embodied by the 
contents of said sectors stored on the client com- 
puter, 

19. The apparatus in claim 18 wherein the processor, in 
response to the executable instructions: 

obtains, from a second server, an address of the image file 
stored on the first server. 

20. The apparatus in claim 19 wherein the processor, in 
^0 response to the executable instructions: 

obtains a boot file from a second network server, the boot 
file comprising real-mode client disk emulation code; 
and 

produces the boot sector download request through 
executing the boot file, wherein the boot sector request 
contains an identification of the first server and the 
name of the image file. 

21. The apparatus in claim 20 wherein the first and second 
servers are the same server or different servers connected to 
the network. 

22. The apparatus in claim 20 wherein the image com- 
prises client 0/S files and application program files. 

23. The apparatus in claim 20 wherein the first server 
provides the client disk emulation, on a sectorized basis, 
while a processing mode of the client computer changes 
from real to protected and the client 0/S takes ownership of 
a network interface situated in the client computer and 
connected to the network. 

24. The apparatus in claim 23 wherein the processor, in 
response to the executable instructions: 

downloads, as part of the image file, a transport driver; 
and 

executes, as one of the cUent 0/S processes, the transport 
driver such that each of the client disk access requests, 
generated by the client computer while the client 0/S is 
being booted, is directed to the first server so as to 
retrieve contents of a corresponding sector of the image 
file stored on the first server in lieu of accessing a sector 
associated with a disk locally situated at the client 
computer, whereby, through use of the transport driver 
and while the client 0/S is being booted, an actual 
source of the contents of the sectors remains transpar- 
ent to the client 0/S. 

25. The apparatus in claim 24 wherein the processor, in 
response to the executable instructions; 

handles, while the client computer is operating in the real 
processing mode, client disk access operations through 
a real mode interrupt handler procedure so as to gen- 
erate ones of the plurality of requests; 
handles, while the client computer is operating in the 
protected mode, client disk access operations through 
pre-defined client O/S network procedures so as to 
generate subsequent ones of the plurality of requests; 
detects, as the client 0/S processes are being activated, a 
transition in the client processing mode from real to 
protected; and 
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during the transition, controls a changeover in handling 
client disk access operations from the real mode inter- 
rupt handling procedure to the client 0/S network 
procedures to generate said subsequent ones of the 
plurality of requests. 

26. The apparatus in claim 25 wherein the pre-defined 
client 0/S network procedures comprise an input/output 
subsystem (LOS) process and network driver interface speci- 
fication (NDIS) process. 

27. The apparatus in claim 25 wherein the processor, in 
response to the executable instructions, controls the 
changeover based on whether sufBcient active resources 
then exist in client 0/S as it is booting. 

28. The apparatus in claim 25 wherein processor, in 
response to the executable instructions, employs a 
semaphore-based procedure for detecting said transition in 
the client processing mode. 

29. The apparatus in claim 25 wherein the processor, in 
response to the executable instructions: 

executes predefined boot code stored in the client com- 
puter which, in response thereto, broadcasts a client IP 
(Internet protocol) request message on the network, 
said client IP request message containing an address of 
the network interface situated in the client computer; 

obtains, from the second server, a reply message to the 
client IP request message, wherein the reply message 
contains an IP address assigned to the client computer, 
an IP address of the first server and an address of the 
boot file stored on the second server, wherein the boot 
file contains the real-mode client disk emulation code 
and a name of an initialization file; 

downloads the boot file from the second server; 

executes the emulation code contained in the boot file, 
once it has been downloaded, so as to initiate real-mode 
client disk emulation through the second server and 
thereafter to download the initialization file from the 
second server, wherein the initiahzation file contains an 
address of the image file residing on the first server and 
an address of the first server; and 

downloads, from the first server and in response to 
execution of the boot file in conjunction with the 
initialization file, a boot sector contained within the 
image file; 

issues, as a result of executing the boot sector, each of said 
plurality of requests, to the second server, to download 
the contents of the plurality of corresponding sectors 
that collectively store the image file; and 

starts execution of various client 0/S processes in the 
cUent computer as sufficient 0/S files are downloaded 
on a sector-by-sector basis from the image file stored on 
the first server. 

30. The apparatus in claim 29 wherein the processor, in 
response to the executable instructions, generates a separate 
random access trivial file transfer protocol (RAIFTP) read 
request message to an RATFTP server in the first server in 
order to download a corresponding one of the sectors of the 
image file, wherein the RATFTP server implements sector- 
ized access to the image file. 

31. The apparatus in claim 29 wherein the pre-defined 
client O/S network procedures comprise an input/output 
subsystem (lOS) process and network driver interface speci- 
fication (NDIS) process. 



10 



15 



20 



25 



30 



35 



45 



55 



32. The apparatus in claim 29 wherein the processor, in 
response to the executable instructions, controls the 
changeover based on whether sufficient active resources 
then exist in client 0/S as it is booting. 

33. The apparatus in claim 29 wherein the processor, in 
response to the executable instructions, employs a 
semaphore -based procedure for detecting said transition in 
the client processing mode. 

34. The apparatus in claim 29 wherein the first and second 
servers are the same server or different servers connected to 
the network. 

35. The apparatus in claim 29 wherein the image com- 
prises client 0/S files and application program files. 

36. The apparatus in claim 23 wherein the processor, in 
response to the executable instructions: 

executes predefined boot code stored in the client com- 
puter which, in response thereto, broadcasts a client IP 
(Internet protocol) request message on the network, 
said client IP request message containing an address of 
the network interface situated in the client computer; 

obtains, from the second server, a reply message to the 
client IP request message, wherein the reply message 
contains an IP address assigned to the client computer, 
an IP address of the first server and an address of the 
boot file stored on the second server, wherein the boot 
file contains the real-mode client disk emulation code 
and a name of an initialization file; 

downloads the boot file from the second server; 

executes the emulation code contained in the boot file, 
once it has been downloaded, so as to initiate real-mode 
client disk emulation through the second server and 
thereafter to download the initialization file from the 
second server, wherein the initialization file contains an 
address of the image file residing on the first server and 
an address of the first server; and 

dowaloads, from the first server and in response to 
execution of the boot file in conjunction with the 
initialization file, a boot sector contained within the 
image file; 

issues, as a result of executing the boot sector, each of said 
plurality of requests, to the second server, to download 
the contents of the plurality of corresponding sectors 
that collectively store the image file; and 

starts execution of various client 0/S processes in the 
client computer as sufficient 0/S files are downloaded 
on a sector-by-sector basis from the image file stored on 
the first server, 

37. The apparatus in claim 36 wherein the processor, in 
response to the executable instructions, generates a separate 
random access trivial file transfer protocol (RATFTP) read 
request message to an RATFTP server in the first server in 
order to download a corresponding one of the sectors of the 
image file, wherein the RATFTP server implements sector- 
ized access to the image file. 

38. The apparatus in claim 36 wherein the first and second 
servers are the same server or different servers connected to 
the network. 

39. The apparatus in claim 36 wherein the image com- 
prises client 0/S files and application program files. 
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